直击灵魂：软件研发的第一性原理与10倍效能
最近马斯克（Elon Musk）要收购twitter，闹得满城风雨。
国内某些亏损严重（如今年亏损800多亿、去年是1166亿，甚至超过一年收入）的大厂，更应该设法让马斯克收购。
为什么这么说呢？因为一旦大厂被马斯克收购，大厂的研发效能可以提升十倍、几十倍，员工可以裁掉50%甚至90%，这样很快就能转亏为盈。
这是因为马斯克第一性原理用得非常好，10倍效能提升是大概率事件。如果一般人的目标是在现在的基础上改进10%，马斯克的目标就是在现有基础上做到10倍。《连线》杂志的Jack Stewart 发现：如果一件事，在马斯克的世界里用1年完成，到了别人的世界就要7～8年。例如，马斯克创立的 SpaceX公司猎鹰9号火箭，不仅能回收，而且复用周转时间降到了21天，一次能发射53颗“星链”卫星，SpaceX 火箭发射的成本只是 60 年代俄罗斯联盟号的成本的3%（即1/30）。还有，2017年马斯克创立了boring公司，两年不到的时间，就在旧金山建成了总长1.83公里的隧道。如果按照传统的地铁方式挖掘预估成本是11亿美金，而boring公司的施工成本仅为1000万美金，仅为百分之一。
言归正传，开始讨论下面4个问题：
第一性原理其实是一种思维方式 软件研发的第一性原理是什么？ 在软件研发中，如何用好第一性原理？ 用好第一性原理带来的收益？
1. 第一性原理其实是一种思维方式
最早提出第一性原理思维的人是古希腊伟大的哲学家亚里士多德，把它定义为“认知事物的第一基础”，而著名的法国哲学家、数学家笛卡尔将其描述为 “系统性地怀疑一切值得怀疑的事物，直到你获得无可置疑的真相”（类似批判性思维）、维基百科的定义为：从基本的定律出发，不外加假设与经验拟合的推导与计算。第一性原理常被延伸为 “回溯事物本质，敢于怀疑过去的设定、打破过去的认知，通过演绎法推导，最终得出新的结论”，所以可以说，是认知事物的哲学思想，也就是分享与解决问题的思维方式。
不管哪个领域，其事物都存在其本质的东西，正如老子说 "人法地、地法天、天法道、道法自然"。所以，我们要回到事物的本质上，就是要回到自然法则上，回到物理规律上，从而抓住事物最本质的特征，依据事物固有特性去推导、分析、演绎事物的变化规律，进而洞悉事物在不同场景下的表现形式，而不是随大流、人云亦云，不会只看到事物的表面现象，不会生搬硬套别人的制度、流程和经验，不会在复杂环境中、不确定因素影响下迷失了自己前进的方向。
第一性原理思维直击事物本质，产生的效果就大不一样。正如Google X实验室主管泰勒就说：“尝试做一样新东西，不外乎那么两种风格，一种是小幅变动，比如工艺改进、造型优化等，这时往往得到只有10%的改进；但如果要获得真正的巨大革新（10倍的改进），一般来说你就得重新开始，尝试完全不一样的方式，必须打破一些基本的假设。” 甚至硅谷流行这样一种观念：把一件事情做到10倍好，比做到10%要容易得多。
循序渐进式的进步依靠的是苦干、更多的资源，而10倍的进步则建立在勇气和创造力之上，靠的是第一性原理的思维方式，是巧干。
“第一性原理”自 2017 年马斯克在采访中被提及后，最近几年在互联网和投资圈流行，但在软件研发中思考得不够。
软件研发的第一性原理是什么？
一般来说，先要思考和软件研发相关的一些基本问题，例如：什么是软件？为什么要开发软件？软件是如何开发出来的？软件从哪里来、到哪里去？
例如：软件 = 程序 + 文档 = 数据结构 + 算法 + 文档，让抽象的软件变得更加具体了，软件的开发转化为数据结构和算法的设计与实现、文档的编写。一个软件的交付，数据结构和算法是不能省的，但文档是可以省的，尽可能简洁。当软件设计简单、UI界面非常友好，就不需要什么用户手册，今天绝大多数App没有在线帮助（文档）。
软件是如何开发出来的？简单地说，通过需求定义、设计和编程、测试、集成构建起来的，哪个环节可以省去？哪个环节有最大的优化空间？按某些管理者的习惯性思考，任何环节都不可去掉，甚至有的管理者还说，每个环节都没什么优化空间了，我们已经优化得很好了。真的是这样吗？
软件其实就是团队之间、团队内部研发人员之间协作开发过程中产生的，正如马斯克所说，“剩下来的成本都是人类协作过程中产生的，那就有优化的空间”，而且比尔盖茨还说过 “一个杰出的程序员的价值是普通程序员的一万倍”。所以软件研发的各个环节就有优化空间，这也是为什么Amazon团队要招最好的人，并追求2-piece pizza这样的小团队。人力成本在软件研发成本中占的比重很大，“人员优化”是最值得去做的。
软件研发的第一性原理：软件研发是人的智力活动，人是决定的因素，所以在软件研发中需要优化与人相关的一切活动，包括个人能力和团队协作。
从第一性原理出发，要优化人员，首先就要优化待开发的软件本身。正如，我在给学生讲解敏捷开发模式时，强调 “研发组织分解” 或 “建立小团队”的前提是：待开发的系统能够分解。系统分解得越干净，小团队才能更独立地工作，工作效率才越有保证。这也是为什么今天微服务、serverless 很流行。系统的复杂性取决于业务的复杂性，如果业务很复杂，软件系统用什么架构（微服务、serverless等）都没用，这时就必须进行业务重组、业务变革或业务架构的优化。虽然业务驱动研发，但业务不是一成不变的，一定是可以改变的，我们要勇于打破业务惯例，大胆革新。
从第一性原理出发，在业务和软件本身优化之后，我们可以开始优化软件研发的各种活动，砍掉一些不必要的环节，把一些环节交给工具或机器人去做，进而可以优化组织和团队。例如：
需求可以自动采集吗？如构建用户反馈系统，自动收集用户需求；
借助知识图谱、机器学习等进行需求分析和提炼；
构建需求模型，自动生成代码；
编程辅助机器人自动补充代码、实时代码检查分析等；
封装成标准组件、原子服务等；
利用JVM、容器技术，减少对环境的依赖；
集成了自动化测试、自动化部署的交付流水线
......
人多了，其实往往是坏事，正如樊登在其《低风险创业》一书中说，如果创业时钱多不是好事，因为钱多就猛招人、大做广告、买流量等，表面上看，不好的产品销售不错，会给自己错觉，觉得开发出来的产品是好产品，但最后钱烧光了，产品卖不出去了，还要裁人。创业时钱少，就不会花精力在营销上，而是能省则省，踏踏实实做产品，靠产品功能和质量赢市场。
道理相通，软件研发中，一旦人不够，如果我们就喊缺人、招人，我们就不会去努力思考如何优化工作、如何减少不必要的浪费等。如果不招人，我们就会朝思暮想去优化工作，反而带来很高的效能。
当然，我们并不反对人多力量大，但如何有效分配人力，精准使用人力，也是研发效能更高的目标，如我军著名的三三制战术（非人海战术，它也被美国西点军校奉为经典战术之一），起源于抗日战争，成熟于解放战争，大量运用于抗美援朝中，发挥我军人数上的优势，降低敌军武器上的优势。
概括起来，软件研发有许多地方可以进行创新，从第一性原理出发，软件研发降本增效的基本要点是：
优化与人相关的一切活动（包括人与组织）
把招对人、培养人的能力放在第一位，尽量少招人
做正确的事，以终为始，从客户真实需求出发构建软件
从业务架构、系统架构开始，内建质量，追求极致的简约
如果能让工具做的事情，尽可能让工具做
尽可能标准化、组件化、原子化、服务化。
用好了第一性原理出发，就能达到“10倍效能”，其实不一定能达到10倍效能，“10倍效能”只是一个代名词（思维方式），是指高效能，可能是2倍、3倍，也有可能是20倍、30倍。即使是2倍效能，也很好了。想想像腾讯、阿里这样的大厂，效能能翻一倍，那将是奇迹。
我们期待奇迹发生，相信奇迹能够发生。